There are numerous fonts that are resident within a printer. In many conventional printers known in the prior art, these fonts are stored in non-volatile memory, then loaded into virtual memory (i.e., RAM) when the printer is initialized. In these conventional printers, any change to a resident font is lost the next time the printer is initialized. If a modified font or "replacement" font by the same name was downloaded to the printer's non-volatile memory storage device from a host computer, it would not be stored in the virtual memory and used by the printer to create bitmaps for any character fonts. Instead, the printer would always look to the virtual memory to find that font (by that same name), and the original resident font data would always be used to print the document, ignoring the downloaded modified font or replacement font.
U.S. Pat. No. 5,367,618 (by Ishida) discloses a document processing apparatus that includes a "transmitting unit" and a "receiving unit," which correspond, respectively, to a host computer and a printer. The host computer selects a particular font data that corresponds to character codes contained in document data for a print job that is to be later transmitted to the printer. Before sending the document data, it is determined whether or not the correct font data set has already been installed in the printer. If not, then the host computer transmits the selected font data to the printer, where it is temporarily stored so that this font data can be used for printing the document data after that document data has been received from the host computer. In one embodiment, the font data received by the printer, and temporarily stored in the printer's memory, is automatically deleted after the print job has been completed.
U.S. Pat. No. 5,148,293 (by Miyachi) discloses an image forming apparatus that includes a memory area that contains an erasable font pattern. Earlier laser printers contain "basic" font patterns, usually stored in a ROM, and these basic font patterns are used to derive bold fonts, italic fonts, and modified fonts (that are rotated). Since these derived fonts occupy a certain portion of RAM, the amount of the buffer area for expanding an image into a bitmap is reduced. In the Miyachi invention, the RAM memory area of the printer is divided into two areas: (1) a buffer area to hold derived fonts, and (2) a buffer area to hold expanded bit image data (e.g., for bitmaps). When the memory area provided for the bit image expansion is filled up during the generation of the bitmap, the Miyachi invention looks at the "modified font pattern storage area" to see if there are any unused portions that can be re-allocated for other purposes. If there are portions of the modified font pattern storage area that are unused, then these portions will be allocated to hold further bitmap information while the bit image is being expanded.
U.S. Pat. No. 5,410,640 (by Morikawa) discloses a font management system that includes a font memory which stores a plurality of fonts, each having a plurality of attributes. The system also uses RAM which contains a "priority register table." A "font selection code" is transmitted from a host computer to the printer, and this code contains attribute information that is used to select a single font from among the plurality of available fonts. The attribute information contained in the font selection code is compared to attribute information stored in the font memory in the order of priorities of the fonts stored in the system RAM. The system can select at high speed a desired font having the correct attribute information, as contained in the font selection code. Since the comparison of the attributes is performed in the order of respective priority, a font having certain attributes can be selected within a comparatively short time period. Since it is likely that different priority data are requested for a certain font, including the font point size and the font type, the particular font data having the higher priority will be selected at a high speed. The user is permitted to select the priority of the various font types and other font characteristics, and therefore, the most common font set would be most quickly selected in normal circumstances at a host computer used by that particular user.
U.S. Pat. No. 5,542,050 (by Onozawa) discloses a font information transfer system that uses a workstation and a printer, in which both new and previously-defined fonts can be sent from the workstation to the printer. In earlier systems if new font characters are desired, the general practice was to render such new characters at the workstation and send a bitmap to the printer; however, this required a large amount of data to be sent over the network between the workstation and the printer. The Onozawa printer is provided with a "character development means" that can create a brand new characters based upon data received from the workstation. At the same time, the printer includes a "font registration means" so that previously-defined characters can be printed merely by sending "code data" of that particular character to the printer. If a new character is desired, the workstation can extract "basic font data" of an existing character and allow a user to make changes to that character while confirming the newly developed character on the monitor. Once the user has corrected any errors, the font is registered in a "font registration means" and a number called "attestation data" along with a name is registered in the "font registration means." In this situation, not only the character code must be sent to the printer, but also "procedure data" and "attestation data" must be transmitted to the printer. Once this information is received at the printer, it is stored in a "font registration means" and the character code and layout information are stored in the printer's "code memory." Now that the new font character has been registered in the printer, the "character development means" in the printer can generate the font from basic font data stored in the printer's font data memory. Since the new character has been generated and stored in the printer, the workstation can call for that character to be printed later by only sending the "attestation data" to the printer. By use of the Onozawa invention, a new character can be printed by sending only the character's code data, font generation procedure data, and attestation data. It is not necessary to transmit the document in bitmap image data form from the workstation. Of course, each new character that is to be printed must have a character code first defined at the workstation, and then registered both at the workstation and later at the printer. This would not be considered a resident font since a new code name is created for each new character that is to be created and printed.
U.S. Pat. No. 5,239,621 (by Brown) discloses a printer having a "Flash memory" that stores fonts and macros, under operator control. The Flash memory comprises an electrically erasable programmable read only memory (EEPROM). Since the Flash memory is non-volatile, fonts or macros that are downloaded to the printer can be stored and, even after a power interruption, retrieved for later use. Brown also discloses a printer that has the capability of responding to more than one printing language, and can store downloaded information relating to more than one language. If the print language is "Postscript.TM." and particular fonts are stored for use with Postscript, then the printer has a particular order that it uses to search for such fonts when these fonts are called for in a print job. In the Postscript scenario (i.e., for PostScript Level 1), the search order is: RAM, Flash, Cartridge, Resident, and Disk. If the printing language is "PCL5" or "PPDS," then the search order for fonts and macros in the printer is as follows: RAM, Flash, Cartridge, and Resident.
U.S. Pat. No. 5,617,525 (by Sugaya) discloses an image output device that converts character codes into character patterns in advance of printing, and stores these character patterns in a font cache memory. When one of the character codes is received as a printing instruction, the pre-converted character pattern is used for printing. While much of this invention is prior art, one of its improvements is that it can identify character dot patterns that are prepared using different font scalers. The Sugaya printer includes a first font memory used to store an outline font to be used by a first font scaler, and a second font memory that stores an outline font to be used by a second font scaler. A cache memory is included to store character patterns to be generated based upon the outline fonts stored in the first and second font memories. Other memory space is available for the typical receive buffer, page buffer, and bitmap memory. The character patterns generated by the first and second font scalers are stored in a "pattern area," and the conversion information relative to the character patterns are stored in an "information area." This information area stores font scaler information (which is an identification number representing the composing method of outline font or scalable font) which is also dependent on the font of each independent company's format and each independent character design, and which requires a corresponding magnification change and hardware or software to develop this information into a dot pattern. The information area also includes a character set identifier (that represents the character style, such as "Gothic"), a registered character code, and a character size of the character pattern (defined by its width and height). The character set can also be further defined by parameters such as character pitch, its orientation, the graphic set (e.g., ASCII), and the typeface), and this corresponds to characters of a code system within the font group. In one embodiment, when characters are input to the printer, the system software determines whether the character pattern generated by the same font scaler is either stored or not stored in the font cache memory. If it is not stored, either the first font scaler or the second font scaler is selected according to the font scaler information that is contained with the character data. When this occurs, the appropriate font scaler is used to generate a new character pattern based upon the "read outline font," and the new character pattern is registered in the cache memory. If the character pattern identifies the "same" font scaler information, then the system software determines whether a "same" character set is instructed. If NO, then a new character pattern is generated. If YES, then the system software determines whether a "same" character code is instructed. If NO, then a new character pattern is generated, and if YES, the system software determines whether or not a character of the same size is instructed. If the answer is YES, a corresponding character pattern is read from the font cache memory and is written into the bitmap memory.
Different printer page description languages ("PDL's") such as PCL or PostScript have previously defined rules for locating and selecting resources to satisfy a job's application/driver resource request. For example, an application/driver may request that a particular print job be printed using legal size paper. During processing of this example print job, most PDL's would execute a type of search algorithm to locate an input source with legal size print media. At the conclusion of the search algorithm, an input source is selected by the PDL (i.e., interpreter) processing the print job.
The criteria used for algorithms vary greatly among different PDL's, although paper handling search algorithms are well known in the printing industry. For example, if legal sized media is requested and but not found in a particular set of available input sources, then the PDL "PCL 5e" will choose an input source that supports legal size media and the printer prompts the user to change that particular input source to "legal" paper size. On the other hand, the PostScript PDL may be configured to select an input source that contains a size of print media that is closest to legal size paper, then scale the printed page to fit the actual size of the media in the selected input source.
PDL algorithms to locate font resources also exist, however, these algorithms are less widely known. For example, the PostScript interpreter found in conventional printers manufactured by Lexmark International, Inc. is designed to be compatible with Adobe PostScript Language Level 2, Version 2016. To maintain compatibility and maximize performance when the PostScript interpreter is initialized in a conventional Lexmark printer, a listing of all the PostScript resident fonts stored in the printer is loaded into PostScript's virtual memory (which is an allocated portion of the printer's RAM system). Thus when PostScript receives a print job from the host computer which requests a "resident font," the PostScript PDL (i.e., the PostScript interpreter) can easily locate and select the correct font since a font entry already exists in the virtual memory. If a font is requested from an application/driver that is not a resident font, the PostScript interpreter does not find an entry in the virtual memory, and then executes a search among the font storage devices (including Flash RAM and disk drives) to locate the requested font.
The PostScript PDL font search algorithm is satisfactory as long as all of the fonts stored in the printer (i.e., both resident fonts in RAM as well as fonts stored on disk drives or other storage devices) each have a unique "font name" which is used to request the font. This unique name prevents the PostScript interpreter from selecting the wrong font. However, the PostScript interpreter font search algorithm is not satisfactory if a user is required to modify or to replace a "built-in" resident font. The PostScript interpreter allows a user to store a modified copy of a resident font on a font storage device, however, since the resident copy always forces the interpreter to load an entry in virtual memory (i.e., RAM) which references the resident copy of the font, the modified copy of the font residing on the font storage device cannot be selected by PostScript.
It would be an improvement in printer performance if a user could modify or replace a built-in resident font, and then later have that modified "replacement" font be used to print characters for an actual print job.